Expense tracking, electronic ordering, invoice presentment, and payment system and method

ABSTRACT

Systems and methods are described for electronic invoice presentment and payment processing. Requestors may place an order to purchase goods or services from one or more vendors. Invoice processing includes approval routing and dispute resolution.

CLAIM OF PRIORITY

This application is a divisional of U.S. patent application Ser. No.13/608,747, entitled “Expense Tracking, Electronic Ordering, InvoicePresentment, and Payment System and Method,” filed Sep. 10, 2012, whichis a continuation of U.S. patent application Ser. No. 12/404,958, filedon Mar. 16, 2009, which claims the benefit of U.S. Provisional PatentApplication No. 61/064,605, filed on Mar. 14, 2008, and which is also acontinuation-in-part of U.S. patent application Ser. No. 12/111,794,filed on Apr. 29, 2008, now U.S. Pat. No. 8,005,730, issued Aug. 23,2011, which is a divisional of U.S. patent application Ser. No.10/729,019, filed on Dec. 8, 2003, now U.S. Pat. No. 7,412,418, issuedAug. 12, 2008, and which claims the benefit of U.S. ProvisionalApplication No. 60/431,438, entitled “Method and System for ExpenseTracking,” filed Dec. 6, 2002, and U.S. Provisional Application No.60/495,103 entitled “Electronic Ordering, Invoice Presentment, andPayment System and Method,” filed Aug. 15, 2003. The entire disclosuresof the foregoing applications are incorporated by reference herein.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to a method and system for electronicordering, invoice presentment, and payment.

2. Background of the Technology

There exist in the art paper-based methods and systems for payment ofinvoices, but these systems are typically slow and costly for completingsuch transactions. Automatic payment approval and presentment processesare also known, in which electronic invoices are provided and approved,but these processes do not include all functions necessary forcompletion of a transaction (including, for example, payment). It isfurther known to provide electronic payment approval and disputeresolution processes, but without other necessary features forcompletion of a transaction, such as a payment.

There remains an unmet need in the art to provide a wide range ofelectronic budgeting, ordering, invoice presentment, and paymentfunctions within a single method and system, which are useful, forexample, for large organizations, such as mortgage service companies.There is a further unmet need in the art for a method and system thatprovides a wide range of such functions, while at the same timeproviding enhanced customer assistance and improved system integrityissues among interacting systems.

SUMMARY OF THE INVENTION

The following presents a simplified summary of one or more aspects inorder to provide a basic understanding of such aspects. This summary isnot an extensive overview of all contemplated aspects, and is intendedto neither identify key or critical elements of all aspects nordelineate the scope of any or all aspects. Its sole purpose is topresent some concepts of one or more aspects in a simplified form as aprelude to the more detailed description that is presented later.

According to one aspect, an electronic invoice presentment and paymentsystem comprises a registration and order fulfillment module forreceiving orders from one or more requestors to purchase goods orservices from one or more vendors and an invoice processing module forrouting and approving invoices for orders placed by the one or morevendors, wherein the invoice processing module includes one or morecustom invoice approval rules, the invoice approval rules beingcustomized for each of the one or more requestors.

According to one aspect, a method for electronic invoice processing viaa computer, the computer comprising a process comprises receiving arequest from a requestor to purchase goods or services from a vendor;generating, by the requestor, a purchase order reflecting the requestedpurchase; generating, by the vendor, an invoice for the requestedpurchase; generating, by the requestor, a receiving report or approvalof services rendered; determining, via the processor and based on one ormore requestor-defined rules, whether the invoice can be approved; andupon approval of the invoice, initiating an automated payment to thevendor.

According to one aspect, a computer-implemented method of resolvingdispute associated with an invoice, the computer comprising a datarepository, comprise providing an interface for a requestor to accept orreject an invoice; submitting the invoice for payment if the requestoraccepts the invoice, the invoice being stored by the data repository;providing an interface for the requestor to enter comments to the vendorindicating the reasons for rejection if the invoice is rejected, thecomments being stored in the data repository; and providing an interfacefor the vendor to respond to a rejected invoice or submit a new invoice,if the invoice is rejected.

According to one aspect, a computer-implemented method of evaluating aninvoice for approval, the computer comprising a processor, comprisesreceiving an invoice; determining, via the processor, whether theinvoice total matches the purchase order total indicated on a purchaseorder associated with the invoice; and if the invoice total does notmatch the purchase order total, determining, via the processor and basedon one or more requestor-defined rules, whether to approve the invoice.

According to one aspect, a system for invoice processing comprises aprocessor, a user interface for functioning via the processor, and arepository accessible by the repository, wherein a request is receivedfrom a requestor to purchase goods or service from a vendor, a purchaseorder reflecting the requested purchase is generated by the requestor,an invoice for the requested purchase is generated by the vendor, theprocessor determines based on one or more requestor defined rules,whether the invoice can be approved, and upon approval of the invoice,automatic payment to the vendor is initiated.

According to one aspect, a computer program product comprising computerusable medium having control logic stored therein causing a computer toprocess an invoice, the control logic comprises first computer readableprogram code means to generate a request from a requestor to purchasegoods or services from a vendor, second computer readable program codemeans to generate a purchase order reflecting the requested purchase,third computer readable program code means to generate a receivingreport or approval for services rendered reflecting the receipt of therequested purchase; fourth computer readable program code means togenerate an invoice for the requested purchase, fifth computer readableprogram code means to determine, based on one or more requestor-definedrules, whether the invoice can be approved, and sixth computer-readableprogram code means to initiate automatic payment to the vendor uponapproval of the invoice.

To the accomplishment of the foregoing and related ends, the one or moreaspects comprise the features hereinafter fully described andparticularly pointed out in the claims. The following description andthe annexed drawings set forth in detail certain illustrative featuresof the one or more aspects. These features are indicative, however, ofbut a few of the various ways in which the principles of various aspectsmay be employed, and this description is intended to include all suchaspects and their equivalents.

BRIEF SUMMARY OF THE DRAWINGS

FIG. 1 depicts an exemplary system diagram of various hardwarecomponents and other features in accordance with aspects of the presentinvention.

FIG. 2 depicts a high-level block diagram of an EIPP system, inaccordance with some aspects of the invention.

FIG. 3 depicts a registration and order fulfillment module, inaccordance with some aspects of the invention.

FIG. 4 is a flowchart depicting a client rules approval process, inaccordance with some aspects of the invention.

FIG. 5 depicts an exemplary approval routing screen, according to someaspects of the invention.

FIG. 6 is a flowchart depicting a dispute resolution process, inaccordance with some aspects of the invention.

FIGS. 7A 7C are exemplary screen shots depicting various aspects ofdispute resolution, in accordance with some aspects of the invention.

FIGS. 8 and 9 are exemplary screen shots, in accordance with someaspects of the invention.

FIG. 10 depicts a computer system for implementing various aspects ofthe present invention.

DETAILED DESCRIPTION

An electronic invoice presentment and payment (EIPP) system and methodare described herein. The EIPP system and method brings the entireinvoicing process, from presentment to payment, online using web-basedtechnologies, platforms, and transports.

FIG. 1 depicts an exemplary system diagram 100 of various hardwarecomponents and other features in accordance with aspects of the presentinvention. As depicted in FIG. 1, one or more vendors 110 and requestors120 may be communicatively coupled to an EIPP server 130 over network116. Vendors 110 and requestors 120 may access EIPP server 130 viaterminals 112 and 122, respectively, which may be a personal computer(PC), microcomputer, mainframe computer, telephone device, PDA, or anyother device having a processor and input capability. EIPP server 130may be a personal computer (PC), microcomputer, mainframe computer orany other device having a processor and repository for data or caninterface to a repository for maintained data.

According to some aspects of the invention, requestors may be, forexample, real estate owners or other property holders such as acorporation, bank, or other entity having real estate owned properties.The requestors may order one or more services from vendors inconnections with the sale or management of a property, or any othertransactions.

EIPP server 130 may comprise a plurality of modules forming anintegrated invoice management platform. FIG. 2 depicts a high-levelblock diagram of an EIPP system 130, in accordance with some aspects ofthe invention. EIPP system 130 may include a registration and orderfulfillment module 210, an invoice processing module 220, and a datahandling module 230.

Registration and order fulfillment module 210 may provide for variousfunctions, such as, for example, online vendor registration, submissionand review of purchase orders, and creation of receive reports. Invoiceprocessing module 220 may provide tools for approving and routinginvoices and for electronic dispute resolution. Data handling module 230may be configured to format data to be exchanged into various fileformats, and to perform validation on file transfer between systems.

FIG. 3 depicts registration and order fulfillment module 210 in greaterdetail. Registration and order fulfillment module 210 may include aregistration sub-module 302, a purchase order processing sub-module 304,and a receive reports sub-module 306.

Registration sub-module 302 may provide one or more interfaces, enablingvendors and/or requestors to register to use the EIPP system. Vendorregistration may include providing details of the vendor's business suchas, for example, the business name, address, phone number, emailaddress, services provided, price list, and/or other vendor information.The vendor may also be required to provide banking information which maybe used to remit payments from the requestors. According to someaspects, upon completion of vendor registration, the vendor'sinformation is automatically uploaded to an accounts payable systemassociated with the requestor(s) to ensure smooth payment processing.

Registration sub-module 302 may also provide interfaces enablingrequestors to register. Like vendors, requestors may be required toprovide business information, such as business name, address, phonenumber, and email address. The vendors may also be required to submitbanking and/or credit card information for processing payments.

Purchase order processing sub-module 304 may be provided for generatingelectronic purchase orders. When a requestor wishes to order productsand/or services from a vendor, purchase order processing sub-module 304may generate an electronic purchase order which is transmitted to thevendor.

Receive reports may be used to track items received and accepted by arequestor. As such, receive reports sub-module 306 may be configured tolog orders received and accepted, and to generate a report. Similarly,in the case of services, receive reports sub-module 306 may beconfigured to log a requestor's approval of services rendered. Thereceive reports may be used to validate invoices. For example, if arequestor orders 100 air-conditioners from a vendor and receives 78units, a receive report is generated indicating that 78 units weredelivered. If the requestor accepts the 78 units, the report alsoindicates that the 78 units were accepted.

Referring again to FIG. 2, invoice processing module 220 may providetools for processing invoices including, for example, tools forapproving invoices and for routing invoices to the appropriate partiesfor approval as needed. Some invoices may be approved automaticallywhile others may require approval by one or more approvers designated bythe requestor. According to some aspects of the invention, invoiceprocessing module 220 may be used in conjunction with client-definedrules to evaluate an invoice for automatic approval.

Client-defined rules may include rules that define whether an invoicemay be automatically approved based on the quantity of goods delivered,the invoice price, delivery dates, and/or other factors. For example, aclient may configure rules indicating that a delivery date cannot exceeda predetermined amount of days after the expected received dateindicated on the order report. As other examples, a client may configurerules indicating that an invoice price can or cannot exceed the orderprice, or that a quantity of goods received can or cannot exceed anamount ordered.

To determine whether an invoice can be approved automatically based onuser configured rules such as the examples described above, a rulesengine may be provided as a configurable set of database tables thatestablish relationships, comparisons, and resulting actions amongstinvoice, order, and receiving report data attributes. FIG. 4 is aflowchart depicting a client rules approval process. As depicted in FIG.4, the rules engine may use a three-way mapping of the receive report,the purchase order, and the invoice to determine whether an invoice maybe approved. The purchase order indicates the goods and/or servicesinitially requested by the requestor. The receive report indicates thatthe requestor has accepted or approved the delivered goods or services,and the invoice represents the goods and/or services billed by theclient. Accordingly, the rules engine may validate an invoice bycomparing the values of all three reports.

As depicted at 402, the process begins when a vendor submits an invoice.As depicted at 404, the invoice validation and approval sub-module maydetermine whether the invoice total amount is equal to, greater than, orless than the total amount quoted on the confirmed purchase order. Asdepicted at 406, the invoice validation and approval sub-module may alsodetermine whether the amount charged for each invoice item is equal to,less than, or greater than the per item amount quoted on the purchaseorder. The inquiries depicted at 404 and 406 are evaluated usingpurchase order rules 408.

The price details on the invoice received may be compared to the detailson the purchase order. For example, the cumulative invoice total may becompared to the purchase order total. Likewise, the price for each itemon the invoice may be compared to the price for each item on thepurchase order. Purchase order rules 408, which are pre-configured bythe client/requestor, indicate whether the invoice should be approved.

As depicted at 410, it is determined whether the amount of goodsdelivered is equal to, less than, or greater than the amount of goodsreceived. That is, the amount of items delivered on the invoice iscompared to the amount of items delivered and received. As depicted at412, the invoice date of service may be compared to the purchase orderdelivery date. This includes a comparison of the service delivery dateagainst the service order delivery data specified on the purchase order.As the inquiries performed at steps 410 and 412 include evaluatinginvoices in light of both a purchase order and a receive report, theinquiries are processed by purchase order rules 408 and receipt rule414. Like the purchase order rules, receipt rules may be preconfiguredby the client/requestor.

Invoices that cannot be automatically approved may require approval byone or more designated approvers. FIG. 5 depicts an example of anapproval routing screen 502. As depicted, the approval routing formindicates the invoice number as well as the date and time the invoicewas created. The invoice approval form may also include reasons whyapproval is needed. For example, approval may be needed because the costof the invoice exceeds a predefined threshold. The approver may selectfrom buttons or other selection mechanisms to approve the invoice orreject the invoice. The user may also include approval comments byselecting the appropriate button. According to some aspects of theinvention, multiple parties may be required to approve an invoice. Assuch, the invoice approval screen may display the entire approvalrouting, including the order of the current reviewer within the overallprocess. If the invoice is rejected, the vendor may be sent an email orother indication of such rejection and, e.g., a link to the EIPP systemto obtain further details.

Invoice processing module 220 may also provide tools for online disputeresolution. Online dispute resolution enables a vendor to view commentsassociated with rejected invoices, and respond to the rejection orresubmit the invoice. FIG. 6 is a flowchart depicting a disputeresolution process, in accordance with some aspects of the invention. Asdepicted at 602, a requestor may receive an invoice detailing theproducts ordered and delivered, as well as the cost. Upon reviewing theinvoice, the requestor may determine whether or not to approve theinvoice, as depicted at 604. If the invoice is approved, it is paid, asdepicted at 606.

However, if the invoice is not approved, the requestor may entercomments into the EIPP system detailing the reasons for the rejection,as depicted at 608. The vendor may then be notified by email or othermeans of the rejection, as depicted at 610. The notification may includethe order number and invoice number associated with the rejectedinvoice. The notification may further include, e.g., a link to thesubmitted invoice.

Upon receipt of notification that an invoice has been rejected and uponselection of the link to access the invoice, the vendor may decide torespond to the rejection, or to resubmit the invoice, as depicted at612. If the vendor decides to resubmit, the vendor may generate a newinvoice and forward it to the requestor, as depicted at 614. However, ifthe vendor chooses to respond rather than resubmit, a response may besend via email or other means to the requestor, as depicted at 616. Thevendor may provide comments indicating why the invoice should beapproved.

As depicted at 618, the requestor may then receive an email or othernotification that the vendor has responded to the rejection of theinvoice. According to some aspects, the notification may provide optionsfor approving or rejecting the invoice again right from the email. Forexample, the email message may include an approve button and a rejectbutton, each of which, when selected, would transmit the appropriatemessage to the vendor. In other aspects, the email message may contain alink to the EIPP system where the requestor can review the vendor'scomments and decide whether to approve the invoice or reject it again.As depicted at 620, the requestor determines whether to approve orreject the invoice.

If the requestor again rejects the invoice, a “final message may be sentto the vendor indicating the rejection, as depicted at 622. The messagemay include details about the final rejection, and instructions tosubmit a new invoice. According to some aspects, the new invoice may becreated directly from the email or other message. In other aspects, thevendor may be directed to log into the EIPP system to create a newinvoice. If the requestor chooses to approve the invoice, as depicted at624, the invoice is paid.

FIGS. 7A-7C depict various screenshots, graphical user interfacescreens, and message windows which may be presented during a disputeresolution process, according to some aspects of the invention. Asdepicted in FIG. 7A, a Submitted invoice Details window displays thestatus of a pending invoice. For example, invoice number CBTrashOut,depicted in FIG. 7A, has been rejected. A vendor reviewing this screenhas the option to submit a response or to create a new invoice, asdepicted at 702 and 704, respectively. The user may also view commentsassociated with the rejection, by selecting the link depicted at 706.

FIG. 7B is an example of an Invoice Comments Interface. This interfacemay be provided to a requestor after a vendor has entered commentsregarding an initial rejection of an invoice. The requestor may thenapprove, reject, or respond to the requestor. FIG. 7C depicts an examplefinal rejection email which may be provided to a vendor after an invoicehas been twice rejected. In this example, the requestor's only option isto create a new invoice.

According to some aspects of the invention, an EIPP system may interactwith and exchange data with a plurality of sources. As such, datahandling module 230 may enable the EIPP system to transmit data in avariety of file formats. For example, the EIPP system may be configuredto support fixed flat files, pipe delivered files, comma separatedfiles, Excel™ files, XML files, and/or other file types.

Moreover, to avoid problems associated with missing data transfer, datahandling module 230 may be configured to log errors occurring during atransfer process. Upon logging an error, a system administrator may benotified of the location of the error log. Any transaction associatedwith the error may be re-transmitted after the error has been researchedand corrected. According to some aspects of the invention, a report maybe generated when data is successfully sent and confirmation has beenreceived.

According to some aspects of the invention, approved invoices may beinterfaced with a requestor's accounts payable system. Invoices may bepaid directly via direct deposit to the vendor's bank account after aninvoice has been approved. The vendor may be notified of the payment,for example, via email. Other notification methods, such as facsimilemay also be used. Vendors may also view their invoices and paymentstatus by logging into the EIPP interface.

FIG. 8 is a screen shot of an EIPP work area. The work area may presenta list of all invoices, and indicate the status of the invoice. Invoicesmay be worked on by multiple users. Selecting an invoice may bring upthe invoice details, as depicted in FIG. 9.

The present invention may be implemented using a combination ofhardware, software and firmware in a computer system. In an aspect ofthe present invention, the invention is directed toward one or morecomputer systems capable of carrying out the functionality describedherein. An example of such a computer system 1000 is shown in FIG. 10.

Computer system 1000 includes one or more processors, such as processor1004. The processor 1004 is connected to a communication infrastructure1006 (e.g., a communications bus, cross-over bar, or network). Varioussoftware aspects are described in terms of this exemplary computersystem. After reading this description, it will become apparent to aperson skilled in the relevant art(s) how to implement the inventionusing other computer systems and/or architectures.

Computer system 1000 can include a display interface 1002 that forwardsgraphics, text, and other data from the communication infrastructure1006 (or from a frame buffer not shown) for display on a display unit1030. Computer system 1000 also includes a main memory 1008, preferablyrandom access memory (RAM), and may also include a secondary memory1010. The secondary memory 1010 may include, for example, a hard diskdrive 1012 and/or a removable storage drive 1014, representing a floppydisk drive, a magnetic tape drive, an optical disk drive, etc. Theremovable storage drive 1014 reads from and/or writes to a removablestorage unit 1018 in a well-known manner. Removable storage unit 1018,represents a floppy disk, magnetic tape, optical disk, etc., which isread by and written to removable storage drive 1014. As will beappreciated, the removable storage unit 1018 includes a computer usablestorage medium having stored therein computer software and/or data.

Alternative aspects of the present invention may include secondarymemory 1010 and may include other similar devices for allowing computerprograms or other instructions to be loaded into computer system 1000.Such devices may include, for example, a removable storage unit 1022 andan interface 1020. Examples of such may include a program cartridge andcartridge interface (such as that found in video game devices), aremovable memory chip (such as an erasable programmable read only memory(EPROM), or programmable read only memory (PROM) and associated socket,and other removable storage units 1022 and interfaces 1020, which allowsoftware and data to be transferred from the removable storage unit 1022to computer system 1000.

Computer system 1000 may also include a communications interface 1024.Communications interface 1024 allows software and data to be transferredbetween computer system 1000 and external devices. Examples ofcommunications interface 1024 may include a modem, a network interface(such as an Ethernet card), a communications port, a Personal ComputerMemory Card International Association (PCMCIA) slot and card, etc.Software and data transferred via communications interface 1024 are inthe form of signals 1028, which may be electronic, electromagnetic,optical or other signals capable of being received by communicationsinterface 1024. These signals 1028 are provided to communicationsinterface 1024 via a communications path (e.g., channel) 1026. This path1026 carries signals 1028 and may be implemented using wire or cable,fiber optics, a telephone line, a cellular link, a radio frequency (RF)link and/or other communications channels. In this document, the terms“computer program medium” and “computer usable medium” are used to refergenerally to media such as a removable storage drive 1080, a hard diskinstalled in hard disk drive 1070, and signals 1028. These computerprogram products provide software to the computer system 1000. Theinvention is directed to such computer program products.

Computer programs (also referred to as computer control logic) arestored in main memory 1008 and/or secondary memory 1010. Computerprograms may also be received via communications interface 1024. Suchcomputer programs, when executed, enable the computer system 1000 toperform the features of the present invention, as discussed herein. Inparticular, the computer programs, when executed, enable the processor1010 to perform the features of the present invention. Accordingly, suchcomputer programs represent controllers of the computer system 1000.

In an aspect of the present invention where the invention is implementedusing software, the software may be stored in a computer program productand loaded into computer system 1000 using removable storage drive 1014,hard drive 1012, or communications interface 1020. The control logic(software), when executed by the processor 1004, causes the processor1004 to perform the functions of the invention as described herein. Inanother aspect of the present invention, the invention is implementedprimarily in hardware using, for example, hardware components, such asapplication specific integrated circuits (ASICs). Implementation of thehardware state machine so as to perform the functions described hereinwill be apparent to persons skilled in the relevant art(s).

While the foregoing disclosure discusses illustrative aspects and/orembodiments, it should be noted that various changes and modificationscould be made herein without departing from the scope of the describedaspects and/or embodiments as defined by the appended claims.Furthermore, although elements of the described aspects and/orembodiments may be described or claimed in the singular, the plural iscontemplated unless limitation to the singular is explicitly stated.Additionally, all or a portion of any aspect and/or embodiment may beutilized with all or a portion of any other aspect and/or embodiment,unless stated otherwise.

1. A computer-implemented method of resolving a dispute associated withan invoice, the computer comprising at least one processor, the methodcomprising: providing, via the at least one processor, a first interfacefor a vendor to upload an invoice; transmitting, via the at least oneprocessor, the invoice to a requester of an item associated with theinvoice for approval of the invoice; transmitting, via the at least oneprocessor, notification of the invoice being rejected in response to adetermination that the requester rejects the invoice; providing, via theat least one processor, a second interface for the vendor to viewcomments entered by the requester indicating the reasons rejecting theinvoice, in response to a determination that the requester rejects theinvoice; and receiving, via the at least one processor, comments fromthe vendor responding to the rejected invoice.
 2. Thecomputer-implemented method of claim 1, further comprising providing,via the at least one processor, a third interface for a vendor to submita registration to use the first interface for the vendor to upload aninvoice.
 3. The computer-implemented method of claim 2, furthercomprising automatically transmitting, via the at least one processor,information submitted during the registration to the first interface forthe vendor to upload an invoice.
 4. The computer-implemented method ofclaim 1, wherein the second interface for the vendor to view commentsentered by the requester indicating the reasons rejecting the invoicefurther comprises a fourth interface for the vendor to resubmit theinvoice to the requester.
 5. The computer-implemented method of claim 1,wherein receiving the comments from the vendor responding to therejected invoice comprises receiving, via at least one processor, anelectronic mail message comprising the comments.
 6. Thecomputer-implemented method of claim 5, wherein the electronic mailmessage further comprises a fifth interface for the requestor to selectto approve or reject the invoice.
 7. The computer-implemented method ofclaim 6, wherein the vendor receives a notification corresponding to therequestor's selection to approve or reject the invoice.
 8. A system forresolving a dispute associated with an invoice, the system comprising:at least one processor; an invoice receiving module for receiving, viathe at least one processor, an invoice from a vendor; an invoicetransmitting module for transmitting, via the at least one processor,the invoice to a requester of an item associated with the invoice forapproval of the invoice; an approval module for processing with the atleast one processor, the invoice through an approval process based on atleast one approval rule defined by the requester; and a notificationmodule for transmitting, via the at least one processor, notification ofthe invoice being rejected in response to a determination that theinvoice was rejected by the approval module.
 9. The system of claim 8,further comprising an interface for the vendor to view comments enteredby the requester indicating the reasons rejecting the invoice, inresponse to a determination that the invoice was rejected by theapproval module.
 10. The system of claim 9, further comprising acomments module for receiving, via the at least one processor, commentsfrom the vendor responding to the rejected invoice.
 11. The system ofclaim 8, wherein the invoice is rejected by the approval module inresponse to a determination that the requester has manually rejected theinvoice.
 12. The system of claim 8, wherein the invoice is rejected bythe approval module in response to a determination that a total of theinvoice does not match a purchase order total indicated on a purchaseorder associated with the invoice.
 13. The system of claim 12, furthercomprising a payment module for submitting, via the at least oneprocessor, payment in response to a determination that the approvalmodule approved the invoice.
 14. The system of claim 13, wherein theapproval module comprises an interface for the requester to accept orreject the invoice.
 15. The system of claim 14, further comprising adata repository in communication with the approval module and a disputeresolution module, the dispute resolution module comprising an interfacefor the requester to enter comments to the vendor associated with therejected invoice indicating the reasons for rejection, the commentsbeing stored in the data repository.
 16. A computer-implemented methodof resolving a dispute associated with an invoice, the computercomprising at least one processor, the method comprising: receiving, viathe at least one processor, an invoice from a vendor; processing, viathe at least one processor, the invoice through an approval and paymentprocess; transmitting, via the at least one processor, notification ofthe invoice being rejected in response to a determination that arequester of an item associated with the invoice rejects the invoice;and receiving, via the at least one processor, comments from the vendorresponding to the rejected invoice.
 17. The computer-implemented methodof claim 16, further comprising providing, via the at least oneprocessor, an interface for the vendor to view comments entered by therequester indicating the reasons rejecting the invoice, in response to adetermination that the requester rejects the invoice.
 18. Thecomputer-implemented method of claim 17, further comprising receiving aresubmitted invoice after a vendor views comments entered by therequester indicating the reasons rejecting the invoice.
 19. Thecomputer-implemented method of claim 18, further comprisingfacilitating, via the at least one processor, payment in response to adetermination that the approval module approved the resubmitted invoice.20. The computer-implemented method of claim 19, further comprisingsubmitting, via the at least one processor, payment to the vendor inresponse to the determination that the approval module approved theresubmitted invoice.